home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 3 / QRZ Ham Radio Callsign Database - Volume 3.iso / digests / tcp / 930266.txt < prev    next >
Internet Message Format  |  1994-06-04  |  8KB
  1. Date: Wed, 13 Oct 93 04:30:05 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V93 #266
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Wed, 13 Oct 93       Volume 93 : Issue  266
  11.  
  12. Today's Topics:
  13.              Log file not written after crash in KA9Q NOS
  14.                      NetRom Protocol info wanted
  15.                    NOS telnet echo option problem?
  16.                            Packet FTP Site
  17.                           SMTP transparency
  18.                       TCP-Group Digest V93 #265
  19.  
  20. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  21. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  22. Problems you can't solve otherwise to brian@ucsd.edu.
  23.  
  24. Archives of past issues of the TCP-Group Digest are available
  25. (by FTP only) from UCSD.Edu in directory "mailarchives".
  26.  
  27. We trust that readers are intelligent enough to realize that all text
  28. herein consists of personal comments and does not represent the official
  29. policies or positions of any party.  Your mileage may vary.  So there.
  30. ----------------------------------------------------------------------
  31.  
  32. Date: Tue, 12 Oct 93 23:59 PDT
  33. From: bob@nyssa.wa7ipx.ampr.org (Bob Finch)
  34. Subject: Log file not written after crash in KA9Q NOS
  35. To: tcp-group@ucsd.edu
  36.  
  37. In recent versions of KA9Q NOS, the log file is not written out when
  38. NOS crashes.  The following patch fixes this.
  39.  
  40. 73 -- Bob
  41.  
  42. ===================================================================
  43. RCS file: /usr3/bob/radio/cvs/ka9q/dos.c,v
  44. retrieving revision 1.1.1.1
  45. diff -c -r1.1.1.1 dos.c
  46. *** /tmp/T0a29743 Tue Oct 12 22:27:59 1993
  47. --- dos.c Sun Oct 10 11:30:14 1993
  48. ***************
  49. *** 208,215 ****
  50.     errno = EINVAL;
  51.     return -1;
  52.    }
  53. !  if(--Refcnt[fd] != 0)
  54. !   return 0; /* Somebody else is still using it */
  55.    regs.x.bx = fd;
  56.    regs.h.ah = 0x3e;
  57.    intdos(®s,®s);
  58. --- 208,228 ----
  59.     errno = EINVAL;
  60.     return -1;
  61.    }
  62. !  if(--Refcnt[fd] != 0) {
  63. !   /*
  64. !    * Somebody else is still using it.  Dup and close it
  65. !    * to make sure the file is written out.
  66. !    */
  67. !   regs.x.bx = fd;
  68. !   regs.h.ah = 0x45;
  69. !   intdos (®s, ®s);
  70. !   if (regs.x.cflag) {
  71. !    if (regs.x.ax < NERROR)
  72. !     errno = _ioerr[regs.x.ax];
  73. !    return (-1);
  74. !   }
  75. !   fd = regs.x.ax;  /* close the duped file */
  76. !  }
  77.    regs.x.bx = fd;
  78.    regs.h.ah = 0x3e;
  79.    intdos(®s,®s);
  80.  
  81. ------------------------------
  82.  
  83. Date: Tue, 12 Oct 1993 21:38:13 -0600 (MDT)
  84. From: William Ti Baggett <wbaggett@nmsu.edu>
  85. Subject: NetRom Protocol info wanted
  86. To: TCP-Group@ucsd.edu
  87.  
  88. Hello,
  89.  
  90. I am an engineering student and I am writing a paper on the routing
  91. methods of AX.25, NetRom and TCPIP. In intend to describe how each
  92. protocol routes packets and compare the differences between them. 
  93.  
  94. I am particularly looking for a Net/Rom spec document, but would also be
  95. interested in finding further information on AX.25, TheNet, and TCP/IP.
  96. FTP sources, addressed, and or phone numbers would be greatly appreciated.
  97.  
  98. Thanks,
  99. Tim, AA5DF
  100.  
  101. (Reply to me direct if possible)
  102.  
  103. ********************************************************************
  104. Tim Baggett, AA5DF                    Electrical Engineering Student
  105.                                       New Mexico State University       
  106. Internet: WBAGGETT@DANTE.NMSU.EDU     
  107. AMPR: AA5DF@NMSUGW.AMPR.ORG           US Snail: 1970 Buchanan Avenue
  108. Twisted Pair: (505) 523-6829                    Las Cruces, NM 88001
  109. ********************************************************************
  110.  
  111. ------------------------------
  112.  
  113. Date: Tue, 12 Oct 93 1:44:42 HST
  114. From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
  115. Subject: NOS telnet echo option problem?
  116. To: tcpgroup@ucsd.edu
  117.  
  118. I've noticed a problem in the way the NOS telnet server handles echo option
  119. negotiation when talking with a LINUX telnet client.  Here's a typical option
  120. trace: 
  121. --------
  122. Will show option processing.
  123. telnet> open 44.14.10.43
  124. Trying 44.14.10.43...
  125. Connected to 44.14.10.43.
  126. Escape character is '^]'.
  127. SENT DO SUPPRESS GO AHEAD
  128. SENT WILL TERMINAL TYPE
  129. SENT WILL NAWS
  130. SENT WILL TSPEED
  131. SENT WILL LFLOW
  132. SENT WILL LINEMODE
  133. SENT WILL ENVIRON
  134. SENT DO STATUS
  135.  
  136. KA9Q NOS (wh6aq.ampr.org)
  137.  
  138. login: ah6bw
  139. RCVD WILL ECHO
  140. SENT DO ECHO
  141. Password: RCVD WONT ECHO
  142. SENT DONT ECHO
  143.  
  144. [JNOS-1.10x9-HM$]
  145. -----------------
  146.  
  147. In the above, NOS is setup with 'echo accept' (the default).  LINUX
  148. receives from NOS a WILL ECHO which it acknowledges, but AFTER I enter the
  149. password, NOS then sends a WONT ECHO and LINUX goes into a local echo mode.
  150. Ordinarily this wouldn't be too bad but anytime a carriage return is
  151. entered a '^M' is displayed.
  152.  
  153. On the one hand if 'echo accept' is in effect, why should NOS be
  154. sending a WONT ECHO in the first place?
  155.  
  156. On the other hand, it it says it WONT ECHO, why does it make an
  157. exception for the carriage return?
  158.  
  159. I'm sooo confused.  Is there a way to work around this problem without
  160. having to resort to line mode in telnet?
  161.  
  162. Antonio Querubin  
  163. tony@mpg.phys.hawaii.edu / ah6bw@uhm.ampr.org / querubin@uhunix.bitnet
  164.  
  165. ------------------------------
  166.  
  167. Date: Tue, 12 Oct 93 17:23:25 EDT
  168. From: crompton@NADC.NAVY.MIL (D. Crompton)
  169. Subject: Packet FTP Site
  170. To: nos-bbs@hydra.carleton.CA
  171.  
  172. I now have a fulltime FTP server online that will carry the latest
  173. code, as I get it, from UCSD, WG7J and others. It is a Windows NT
  174. FTP server. It's domain name is 'crompton.nadc.navy.mil' with an
  175. IP address of 138.60.14.19. 
  176.  
  177. Feel free to use it for updates. There is also an incoming R/W directory
  178. for file transfer. Structure is  /pub/incoming, /pub/packet/...
  179.  
  180. Since this site is on the MILNET, via a net 26 cisco router, access
  181. times may at times be slow to sites outside of MILNET. Let me know
  182. if you experience problems.
  183.  
  184. Doug
  185.  
  186. ------------------------------
  187.  
  188. Date: Tue, 12 Oct 93 11:38:13 MET
  189. From: pa0gri@tophat.cdh.cdc.com
  190. Subject: SMTP transparency
  191. To: tcp-group@ucsd.edu
  192.  
  193. Hello All,
  194.  
  195. I do read a conflict in the RFC:
  196. 1) on send: insert a dot if the first char is a dot.
  197. 2) on rec: delete a leading dot (no matter what follows).
  198.  
  199. Case 1 inserts a dot only is a dot is on the line, so for the wanted
  200. transparency the case ends up to only have a .. on reception.
  201. THERE WIL NEVER be a case of .ANYTHING else as a ..ANYTHING on reception.
  202. The old smtp server is correct in looking at a ".." case for reading
  203. but just finding the first thing on a line is "." is sufficient.
  204. . (test case , 1 dot on this line)
  205. .. (now there are two.)
  206. Regards, Gerard.
  207. PS, will check what I have left on sources.
  208.  
  209. ------------------------------
  210.  
  211. Date: Tue, 12 Oct 93 20:04:06 -0700
  212. From: Johan. K. Reinalda <johan@ECE.ORST.EDU>
  213. Subject: TCP-Group Digest V93 #265
  214. To: TCP-Group@UCSD.EDU
  215.  
  216. this with regard to lzw compression:
  217. -as far as i am aware the step you outline should to it jack, other then
  218. adding some handshaking between the 2 sides to agree on using it and, the
  219. number of bits to use...
  220. I am not sure adding it to pop3 is a good idea, since that would lead
  221. to non-conforming code. But for a single instance i guess, whatever :-)
  222.  
  223. The short packets probably have to do with the sockets being flushed all
  224. over the place to send responses when they are needed. Then what ever
  225. data outstanding (short packet from the comporession) will be send...
  226.  
  227. It should be rather trivial to add compression to all sockets on a system.
  228. Simply hardcode the bits size etc, and add a call to lzwinit() at the
  229. enbd of the socket() call ...
  230.  
  231. 73
  232. Johan
  233.  
  234. ------------------------------
  235.  
  236. End of TCP-Group Digest V93 #266
  237. ******************************
  238. ******************************
  239.